Skip to content

Add additional math methods#140

Open
tychedelia wants to merge 5 commits intoprocessing:mainfrom
tychedelia:feature/135-math-methods
Open

Add additional math methods#140
tychedelia wants to merge 5 commits intoprocessing:mainfrom
tychedelia:feature/135-math-methods

Conversation

@tychedelia
Copy link
Copy Markdown
Member

@tychedelia tychedelia commented Apr 25, 2026

@tychedelia tychedelia changed the title Feature/135 math methods Add additional math methods Apr 25, 2026
SableRaf
SableRaf reviewed Apr 25, 2026
View reviewed changes
Comment thread crates/processing_pyo3/mewnala/math.py Outdated
return (value - start) / (stop - start)


def remap(value, start1, stop1, start2, stop2):
Copy link
Copy Markdown

@SableRaf SableRaf Apr 25, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a blocker but we could potentially add the optional 6th argument from p5.js's version of the map() function: map(value, start1, stop1, start2, stop2, [withinBounds]) where withinBounds is a boolean which (if true) makes the function constrain the return value to the newly mapped range.

@SableRaf
Copy link
Copy Markdown

SableRaf commented Apr 25, 2026 •
edited
Loading

Could we explicitly address the tradeoffs before making a decision on map() vs remap()?

From issue #131 it seems like there are at least two possible directions:

  1. Keep map() for Processing compatibility, possibly by dispatching based on arguments like Processing.py does.
  2. Use remap() to avoid shadowing Python’s built-in map(), like py5 does (see @hx2A's comment on 131)

Note: we should document this type of decisions on GitHub, since not everyone is on Discord and messages there are not publicly available without an account.

@SableRaf SableRaf self-requested a review April 25, 2026 06:18
SableRaf
SableRaf requested changes Apr 25, 2026
View reviewed changes
Comment thread crates/processing_pyo3/mewnala/math.py
@@ -0,0 +1,69 @@
"""Processing math methods and vector/quaternion types."""
Copy link
Copy Markdown

@SableRaf SableRaf Apr 25, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR implements the following functions from Processing4:

sin(), cos(), tan(), asin(), acos(), atan(), atan2(), sqrt(), exp(), log(), ceil(), floor(), degrees(), radians(), sq(), pow(), constrain(), lerp(), norm(), map(), mag(), dist()

It's currently missing:

Copy link
Copy Markdown
Member Author

@tychedelia tychedelia Apr 26, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I should leave a comment to make this clear, but these are available in the global python namespace and I believe match processing semantics already.

Ex:

[I]  char@mbp ~/s/g/p/libprocessing  $ python3                                                                                                                                                                                            compute-2
Python 3.14.4 (main, Apr  7 2026, 13:13:20) [Clang 17.0.0 (clang-1700.6.4.2)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> round
<built-in function round>

Comment thread crates/processing_pyo3/mewnala/math.py
@tychedelia
Copy link
Copy Markdown
Member Author

tychedelia commented May 2, 2026

Could we explicitly address the tradeoffs before making a decision on map() vs remap()?

I feel pretty strongly that shadowing built-ins is the wrong decision. map is a pretty common functional programming idiom in python and it would be frustrating if users were left with the option either to not use the wildcard import (requiring manually importing every processing API item one-by-one) or not be able to express common python patterns.

@catilac
Copy link
Copy Markdown
Contributor

catilac commented May 3, 2026

Could we explicitly address the tradeoffs before making a decision on map() vs remap()?

I feel pretty strongly that shadowing built-ins is the wrong decision. map is a pretty common functional programming idiom in python and it would be frustrating if users were left with the option either to not use the wildcard import (requiring manually importing every processing API item one-by-one) or not be able to express common python patterns.

I want to second this. We don't want to clobber the python ecosystem in being overly opinionated. If this somehow becomes an issue to downstream users we can address it then.

is this ready?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@SableRaf SableRaf SableRaf requested changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Add math methods sin(), cos(), tan(), abs() etc.

3 participants

@tychedelia @SableRaf @catilac